@sneridagh I like the frontend/backend "monorepo" idea for volto addons, I had also written some time ago at https://community.plone.org/t/monorepo-for-plone-volto-addons/18688 to seek opinions on it

Some thoughts (I know you are probably in the middle of the work):
I assume we will have to change the version to something like 4.x, right?
Is it possible to continue using plone/meta or do you think we need to create something similar or ..?
How about having the same version and sharing the changelog between the backend and frontend?

@mamico trying for the first time here.
The whole idea of the new cookieplone setups is that there is no difference between having:

• a project of a Plone site that it will be deployed, eventually
  • each backend and frontend having a "policy" add-on that describe the project
• an add-on, with potentially having a backend and a frontend part
  • where each add-on will be published and released packages

Unified testing e2e, unified compatible releases. Follow semantic versioning in both.

Since this will be the first one, we need to polish the idea, though:

• Should we keep an unified changelog? (I'd say yes, but keeping the particular ones)
• Can we use plone/meta? This is a question that we are currently discussing in the community. To my understanding, this is going to be impossible.
• Unified README? I would do so, yes. With info of the add-ons and their requirements "as a whole".

With the version 4 you mean, when we are ready, we will issue major versions? Yeah, we must, I'd say, if they are really breaking. We will need to deprecate the old repo too and point to here.

This is another lighter approach, which I like, https://github.com/wagtail/wagtail they put mostly in the root of the repo (both setup.py and package.json).

@ericof thanks a lot!!!!

@mamico @cekk @pnicolli this is ready now. We've implemented a new approach in the backend, different from the plone/meta approach, which only works in backend-only Python packages. The idea is to push this approach instead of the plone/meta one. This might need time, but we need a first implementation and experimentation with it. So this way will make it to cookieplone and the new generators.

Also, this will be the first full-fledged hybrid add-on so it will allow us to have lots of feedback for making the above a reality.

TBH, I'd merge it asap, and deprecate the old backend repo, if possible. What do you think?

Let's talk about it during today's meeting.

@mamico @cekk @pnicolli this is ready now. We've implemented a new approach in the backend, ...

@sneridagh Thanks for the awesome work, I will check it out ASAP, definitely before the end of this week.

@mamico @pnicolli I think the things that we should settle still are:

• Unified CHANGELOG.md?
• Unified README?
• Unified version?

What do you think? My take would be to unify the README, but keep the CHANGELOG separated, and do the same for the version, so each add-on has their own life. This will force us to maintain a table with the compatibilities, but as long as we stick to semantic versioning in both sides, it shouldn't be hard.

@mamico @pnicolli I think the things that we should settle still are:

* Unified CHANGELOG.md?

* Unified README?

* Unified version?

What do you think? My take would be to unify the README, but keep the CHANGELOG separated, and do the same for the version, so each add-on has their own life. This will force us to maintain a table with the compatibilities, but as long as we stick to semantic versioning in both sides, it shouldn't be hard.

I see two options:

the first is to have a single version for backend and frontend:
PROS: no possible misalignment errors, because backend and frontend go in complete sync; simple repo tags (4.1.2, 4.1.3, ...)
CONS: need for releases without any change in either component, because of a release of the other one

the second is to be very strict with semanticversion: given independent versions X.Y.Z. But any X.Y version of the frontend must work with any X.Y version of the backend and vice versa, (e.g. 4.1.9 of the frontend must work with 4.1.2 of the backend). Thus a breaking change that requires simultaneous backend and frontend changes must require at least a Y increment.
PROS: independence of releases between backend and frontend.
CONS: need for discipline on semanticversion, more “complicated” repo tags, I imagine something like frontend-4.1.2, backend-4.1.9, ...

I don't have a very strong opinion on the choice ... but on the balance of pros/cons at the moment the former would win

IMO the CHANGELOG follows the version policy.

@sneridagh @pnicolli there is a problemi to discuss: zc.buildout

In my tests adding:

develop +=
   src/volto-form-block/backend/

buildout does not use the package, probably due to lack of setup.py (buildout/buildout#645)

I have not tested with the product egg/wheel